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Requirement: 

To  develop  a  modest  capability  of  simulating  tactical  data  systems  for 
determining  the  criticality  and  difficulty  of  learning  and  retaining 
operator /machine  transaction  skills.  The  simulation  capability  was  to  be 
used  in  a  larger  effort  to  determine  whether  or  not  such  difficulties  can 
be  anticipated  and  reduced,  and  whether  they  are  inherently  hardware, 
software,  or  human  problems. 

Procedure : 

Originally,  it  had  been  intended  (1)  to  perform  an  analysis  of  the 
operational  context  within  which  learning  and  retention  difficulties  would 
be  identified  and  targeted  for  research  and  (2)  to  use  a  commercially  avail¬ 
able  microcomputer  as  the  basic  equipment  around  which  to  develop  a  simula¬ 
tion  capability.  Instead,  the  context  analysis  was  deleted  from  the  effort 
and  the  TACFIRE  Training  System  (TTS)  was  substituted  for  the  microcomputer 
as  the  basic  equipment  for  the  simulation  capability  (SIMCAP).  A  validation 
effort  was  undertaken  to  shake  down  and  debug  the  equipment,  facilities, 
and  procedures  that  make  up  the  TTS  SIMCAP. 

The  components  of  the  TTS  SIMCAP  were  assessed  with  regard  to  seven 
characteristics  for  an  ideal  SIMCAP: 

1.  The  general  information  processing  functions  required  to 
coordinate  artillery  fires. 

2.  Man's  information  processing  capabilities. 

3.  The  characteristics  of  the  information  processing  interface. 

4.  Characteristics  of  combat  situations. 

5.  Meaningful  operator  performance  measures. 

6.  Modifiability  of  operator/commander  consoles. 

7.  A  readily  programmable  and  expandable  computer  to  operate 
the  SIMCAP. 

Findings : 

With  regard  to  the  conduct  of  the  validation  study,  an  insufficient 
amount  of  meaningful  data  was  generated  to  allow  for  statistical  analysis 
of  the  results. 

With  regard  to  the  review  of  the  components  of  the  TTS  SIMCAP,  they  were 
found  to  be  severely  deficient  on  all  seven  characteristics  for  an  ideal  SIMCAP. 


Utilization  of  Findings: 

Findings  from  the  review  of  the  TTS  SIMCAP  components  may  be  useful  in 
conceptualizing,  designing,  and  using  other  simulation  capabilities  intended 
as  vehicles  for  studying  human  factors  problems  in  command,  control,  and 
communication  systems.  The  characteristics  of  an  ideal  SIMCAP  point  to  the 
need  to  go  well  beyond  just  a  physical  capability  for  simulating  the 
man/machine  interface.  System  context  and  human  information  processing 
characteristics  must  be  taken  into  account  by  such  simulation  capabilities 
if  fully  useful  results  are  to  be  obtained  from  them. 
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BACKGROUND 


This  project  was  intended  to  have  been  part  of  a  larger  effort  (1)  to 
identify  the  man-machine  transactions  that  could  cause  difficulty  in  the 
acquisition  and  retention  of  skills  required  to  operate  Army  Field  Artillery 
Tactical  Data  Systems  (AFATDS)  and  that  are  related  to  the  software-generated 
Interface  characteristics  of  the  systems  and  (2)  to  develop  ways  of  countering 
these  difficulties.  An  AFATDS  is  a  command,  control,  and  communication 
system  (C3)  used  to  coordinate  requests  for  and  delivery  of  field  artillery 
fires  in  combat  situations.  The  first  generation  AFATDS  is  the  TACFIRE 
system.  However,  this  project  addresses  both  current  and  future  AFATDS. 

The  objective  of  the  larger  effort  and  of  the  project  is  to  anticipate  the 
kinds  of  skills  required  to  use  different  software  approaches  that  could 
cause  acquisition  and  retention  difficulties  and  that  have  a  significant 
Impact  on  the  operation  of  the  system.  Some  kinds  of  skills  are  more  diffi¬ 
cult  to  learn  than  others.  If  these  difficulties  can  be  identified,  then 
they  might  be  countered  either  through  software  designs  or  through  special 
training  designs  and/or  printed  skill  performance  aids  or  by  means  of 
personnel  assignment  policies. 

The  larger  effort  of  which  this  project  was  a  part  was  proposed  to 
contain  a  preceding  subtask  to  develop  the  context  within  which  acquisition 
and  retention  difficulties  would  be  identified  and  targeted  for  research. 

This  subtask  was  to  consist  of  three  steps: 

1.  Develop  operator  performance  criteria  that  are  based  on  or 
reflect  the  mission  effectiveness  of  the  system. 

2.  Develop  situational  measures  that  are  based  on  the  mission 
demands  placed  on  the  system. 

3.  Identify  the  significant  error-likely  situations  for  AFATDS 
operators . 

The  first  step  was  seen  as  providing  a  necessary  basis  for  the  rest 
of  the  effort  in  order  to  focus  analysis  on  those  difficulties  that  are 
most  significant  for  system  effectiveness.  Those  difficulties  that  have 
significant  impact  on  system  effectiveness  would  be  given  higher  priority 
for  investigation  than  those  that  have  little  or  no  impact  on  system  effec¬ 
tiveness  . 


y 

£ 


c-: 


H 


The  second  step  was  to  have  developed  situational  measures  based  on 
mission  demands  placed  on  the  system.  Operator  performance  should  be 
assessed  within  realistic  combat  scenarios.  The  situational  measures  pro¬ 
vide  a  means  of  specifying  such  scenarios.  However,  all  scenarios  are  not 
equally  difficult.  Hence,  it  is  also  desirable  to  be  able  to  scale  scenarios 
by  difficulty  in  order  to  compare  the  performances  of  operators  operating 
against  different  threats  in  different  environments. 


The  third  step  was  to  identify  particular  software  design  options  from 
the  literature  and  by  means  of  rational  and  theoretical  analyses  that  appear 
to  have  a  high  operator  error  potential  with  regard  to  those  kinds  of  errors 
that  are  significant  for  system  effectiveness.  This  step  was  to  help  ensure 
that  the  operational  scenarios  for  use  in  the  experimental  studies  would  ex¬ 
pose  the  operators  to  situations  likely  to  result  in  errors  of  selected 
kinds.  Having  a  firm  idea  of  the  potential  range  of  the  independent  var¬ 
iables  under  study  would  permit  scenario  development  to  be  driven  by  data 
requirements  rather  than  by  happenstance. 

The  three  steps  in  the  first  subtask  were  to  have  provided  (1)  the  con¬ 
text  within  which  to  develop  an  experimental  simulation  capability  (SIMCAP) 
and  (2)  the  context  within  which  to  formulate  hypotheses  for  experimental 
investigation.  This  report  only  describes  the  development  of  the  simulation 
capability  itself. 

The  three  steps  of  the  first  subtask  were  not  performed.  Hence,  the 
operational  context  within  which  to  design  an  AFATDS  operational  simulation 
was  never  developed.  However,  even  without  this  context,  it  seemed  clear 
that  the  SIMCAP  would  have  to  be  capable  of  emulating  the  software-generated 
interface  characteristics  of  the  existing  TACFIRE,  of  future  TACFIRE  hybrids, 
and  of  future  AFATDS  alternative  design  concepts.  Furthermore,  it  seemed 
clear  that  an  actual  TACFIRE  system  would  not  easily  provide  the  capability 
to  explore  the  full  range  of  possible  software-generated  interface  charac¬ 
teristics  of  future  AFATDS  alternatives.  Without  a  doubt,  the  first  genera¬ 
tion  of  a  system  will  be  limited  because  it  invariably  represents  the  least 
advanced  application  of  a  developing  technology. 

In  addition  to  developing  an  experimental  AFATDS  SIMCAP  the  project  was 
to  conduct  an  initial  series  of  studies  to  validate  the  SIMCAP  facility. 
Validation,  in  this  context,  assesses  the  extent  to  which  inferences  drawn 
from  the  use  of  the  SIMCAP  would  be  similar  to  those  drawn  from  similar  data 
obtained  through  use  of  a  real  system — either  the  existing  TACFIRE  or  some 
future  AFATDS  alternative.  Since  the  TACFIRE  is  the  only  alternative  that 
currently  exists,  the  TACFIRE  is  the  only  available  choice  as  a  validation 
criterion. 


Emphasis  during  the  part  of  the  project  covered  by  this  report  was  to 
have  been  on  the  design  and  validation  of  a  SIMCAP.  Only  that  research  re¬ 
quired  by  the  validation  was  to  be  conducted  at  this  time.  Hence,  there 
was  no  need  to  develop  an  extensive  SIMCAP  for  processing  large  numbers  of 
experimental  subjects. 


RATIONALE  FOR  THE  SIMCAP  DESIGN 


w. 


Originally,  it  had  been  intended  to  use  a  microcomputer  as  the  basic 
equipment  around  which  to  develop  a  simulation  capability.  Four  reasons 
were  cited  by  the  SIMCAP  designers  for  selecting  the  existing  TACFIRE 
system  instead  as  the  hardware  vehicle  for  the  SIMCAP: 

1.  The  TACFIRE  terminal  was  deemed  to  be  radically  different 
from  any  microcomputer  keyboard  because  it  contains  special 
character  keys  not  found  elsewhere.  Furthermore,  these  special 
character  keys  are  not  all  on  the  keyboard.  Some  of  them  are 
located  on  vertical  surfaces  on  the  console  rather  than  on  the 
keyboard  itself.  Some  of  the  special  characters — such  as  the 
end  of  text  symbol — are  not  found  on  any  other  system. 

2.  The  actual  TACFIRE  hardware  would  create  a  certain  amount  of 
realism  or  face  validity  for  subsequent  research  studies. 

3.  The  staff  needed  experience  with  the  actual  TACFIRE  system. 

4.  The  TACFIRE  Training  System  (TTS)  was  available  for  research 
use.  Since  the  TTS  has  eight  artillery  control  console  (ACC) 
operator  positions  and  six  variable  format  message  entry  device 
(VFMED)  operator  positions  tied  to  one  computer,  it  would  make 
it  possible  to  collect  data  on  a  number  of  subjects  at  once. 

Although  a  microcomputer  had  already  been  purchased  for  the  SIMCAP,  the 
use  of  the  TTS  made  it  unnecessary,  since  the  TTS  already  contained  its 
own  computer.  This  reasoning  essentially  equated  the  physical  components 
of  the  SIMCAP  to  the  TACFIRE  Training  System  (TTS).  For  this  reason,  this 
version  of  the  SIMCAP  will  be  designated  as  the  TTS  SIMCAP  to  differentiate 
it  from  other  possible  SIMCAPs. 


CHARACTERISTICS  OF  THE  TTS  SIMCAP 


The  TTS  SIMCAP  consists  of  the  following  parts: 

1.  The  actual  TACFIRE  equipment  consoles  used  at  the  two  operator 
positions — the  ACC  operator  position  (eight  stations)  and  the 
VFMED  position  (six  stations). 

2.  The  TACFIRE  computer  equipped  with  a  larger  memory. 

3.  The  enhanced  PLANIT  computer  language  for  programming  the  TACFIRE 
computer.  PLANIT  is  a  complete  authoring  language  and  operating 
system  for  computer  assisted  instruction. 
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4.  The  dependent  variables  made  available  by  the  TTS  SIMCAP.  These 
variables  are  largely  determined  by  the  student  record  capa¬ 
bilities  of  PLANIT. 

The  TTS  SIMCAP  consoles 


The  TTS  based  SIMCAP  uses  the  same  consoles  used  in  the  existing  TACFIRE 
system.  It  possesses  the  same  displays  and  controls  used  in  the  TACFIRE. 

The  focus  of  the  SIMCAP  design  was  on  the  ACC  (Artillery  Control  Console) 
operator.  FM  6-1,  Field  Artillery  Tactical  Fire  Direction  System,  TACFIRE 
Operations  describes  the  ACC  as  follows: 

This  console  is  the  portion  of  the  battalion  set  used  by  the  people 
controlling  processing  in  the  computer  group.  The  ACC  has  two  display 
scopes:  one  for  displaying  messages  from  external  sources  and  results 
of  processing  and  one  for  selection  of  formats  and  initiation  of 
processing.  The  ACC  is  the  TACFIRE  device  that  must  be  checked  for 
system  functioning.  The  ACC  is  operated  by  the  fire  direction 
sergeant /artillery  control  console  operator  (ACC0)(E6,  13E) .  He 
is  supervised  by  the  fire  direction  officer  (CPT,  13A)  and/or  the 
assistant  S3.  These  personnel  make  decisions  agreeing  or  disagreeing 
with  TACFIRE  solutions,  operate  the  ACC,  and  insure  that  the  system 
is  working  properly.  The  FDO  must  be  physically  near  the  console  to 
tell  the  ACC  operator  what  action  to  take  on  the  various  messages 
processed.  The  ACC  operator  can  cause  computer  action,  transmission 
of  information  to  remote  devices,  and  operation  of  other  associated 
equipment.  The  ACC  operator  is  alerted  to  errors  and  violations  by 
displayed  computer  warnings. 

In  addition  to  the  ACC  the  operator  has  an  electronic  line  printer  (ELP) 
located  just  to  the  right  of  his  console. 

The  ELP  provides  a  paper  printout  of  the  results  of  action  accomplished 
by  the  computer.  These  printouts  are  used  to  review  earlier  computer 
actions  and  to  provide  copies  of  data  stored  in  computer  memory  to 
interested  personnel. 

The  TTS  SIMCAP  Computer 

The  computer  uses  several  mass  core  memory  units  (MCMU) ,  each  of  which 
provides  a  capacity  of  approximately  130,000  computer  words  (bytes).  The 
computers  used  in  battalion  TACFIRE  installations  contains  three  MCMU. 
However,  the  version  used  in  the  TTS  has  been  enhanced  beyond  this  level. 
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The  Enhanced  PLANIT  Computer  Language 

PLANIT  contains  a  number  of  operating  modes.  In  the  system  mode,  the 
operator  is  able  to  create  listings  of  PLANIT  programs,  read  PLANIT  programs 
from  magnetic  tape  or  write  them  to  magnetic  tape,  shut  down  designated 
terminals,  list  student  records,  create  history  tapes,  and  delete  programs 
and  student  records.  In  the  command  mode  an  author  is  able  to  create,  edit, 
and  run  lesson  programs  and  a  student  is  able  to  run  a  program  that  has  been 
released  for  student  access.  The  control  mode  is  used  to  run  lessons  which 
have  complete  control  of  the  students  terminal  and  determine  where  the  output 
is  to  be  written  (top  screen,  bottom  screen,  or  ELP).  However,  PLANIT  lessons 
are  typically  run  in  the  lesson  mode.  Although  the  lesson  mode  does  not  pro¬ 
vide  the  control  over  outputs  provided  by  the  control  mode,  it  does  provide 
other  desirable  characteristics  such  as  allowing  the  student  to  operate  the 
system  in  a  calculator  mode. 

PLANIT  lessons  are  divided  into  sections  called  frames.  The  basic  frame 
is  the  question  frame.  The  question  frame  controls  the  presentation  of  text, 
the  processing  of  answers  to  questions,  and  branching  to  subsequent  frames 
based  on  the  answers  to  the  questions.  Control  mode  processing  uses  question 
frames,  programming  frames,  and  decision  frames.  The  latter  two  define 
functions  and  subroutines  as  well  as  playing  a  role  in  the  presentation  of 
text  and  in  branching. 

The  answer  section  of  a  question  frame  contains  a  list  of  possible 
answers  prepared  by  the  author.  Each  of  these  answers  has  an  identification 
label.  Answers  which  the  author  deems  to  be  correct  are  marked  with  a  "+" 
after  the  label. 

The  PLANIT  student  record  is  a  special  file  created  by  a  PLANIT  lesson 
to  record  the  student's  performance  on  that  lesson.  The  student  record 
normally  records  the  answer  to  question  frames  only.  The  amount  of  time  in 
each  question  frame  is  recorded  in  minutes  and  seconds  along  with  the  answer 
label.  If  a  student's  response  matches  one  of  the  labeled  answers  in  the 
answer  section  of  the  question  frame,  the  label  appears  on  the  student  record 
for  that  frame:  Correct  answers  are  marked  with  a  plus.  If  the  student's 
answer  was  not  anticipated  by  the  author,  a  appears  on  the  student  record 
for  that  frame.  In  addition,  the  student  record  records  the  time  and  date 
the  lesson  was  started  and  the  time  and  date  it  was  stopped.  If  the  lesson 
was  restarted,  that  is  also  indicated  on  the  student  record.  At  the  end  of 
the  record,  the  total  number  of  right  and  wrong  answers  to  the  question  frames 
is  given  along  with  the  total  amount  of  time  spent  on  the  entire  lesson. 


A  PLANIT  history  tape  can  be  created  to  save  the  contents  of  the  entire 
computer  memory  including  all  of  the  student  records.  If  practice  on  a  lesson 
is  interrupted,  the  history  tape  allows  the  operator  to  restore  the  system 
at  a  later  time  to  the  same  condition  it  was  at  when  the  lesson  was  interrupted. 


The  Dependent  Variables 

The  dependent  variables  available  in  the  TTS  SIMCAP  are  determined 
largely  by  the  information  provided  by  PLANIT. 

1.  Number  of  question  frames  to  criterion.  Since  the  PLANIT  student 
records  contain  the  exact  sequence  in  which  question  frames  were 
presented  to  each  student,  a  simple  count  can  be  obtained  of  the 
number  of  frames  required  by  a  student  to  reach  the  training 
criterion. 

2.  Total  training  time  to  criterion.  Since  the  PLANIT  student 
record  records  the  time  spent  in  each  question  frame  by  each 
student,  total  time  can  be  obtained  by  summing  the  individual 
times  for  all  the  frames . 


3.  Number  and  types  of  errors.  The  PLANIT  student  record  only 
records  the  content  of  responses  that  have  been  anticipated 
by  the  author.  It  was  not  considered  possible  to  anticipate 
all  of  the  ways  in  which  students  could  make  errors  to  each 
and  every  question  frame.  Consequently,  it  was  decides  to  use 
the  ELP  located  at  each  student  station  to  record  the  exact 
response  the  student  transmitted  to  the  computer.  After  the 
student  has  finished  a  lesson,  the  printed  ELP  records  can  be 
examined  and  errors  classified  and  counted. 

The  last  two  dependent  variables  were  determined  by  an  artificial  response 
keyed  by  the  student.  It  was  desired  to  separate  the  time  it  took  a 
student  to  decide  what  action  to  take  from  the  time  it  took  him  to  actually 
perform  the  action.  That  is,  it  was  desired  to  measure  the  student's 
decision  time  separately  from  his  performance  time  to  each  question  frame. 

In  order  to  obtain  these  two  measures,  two  button  lights  on  the  switch  panel 
assembly  were  used.  At  the  beginning  of  a  question  frame,  the  message 
"PRESS  'PRIORITY  MESSAGE'  WHEN  READY  TO  CONTINUE"  appeared  in  the  top  screen. 
When  the  student  pressed  the  priority  message  button  the  message  light  went 
off,  the  message  in  the  top  screen  was  replaced  with  a  problem  scenario 
with  instructions,  the  message  "PRESS  'ILL.  SW  ACTION'  WHEN  READY  TO  PERFORM 
TASK"  appeared  on  the  bottom  screen,  and  the  illegal  switch  button  lighted 
up.  After  reading  the  scenario  and  deciding  what  to  do,  the  subject  pressed 
the  illegal  switch  action  button.  This  action  caused  the  light  in  the  button 
to  be  extinguished  and  cleared  the  bottom  screen  so  that  the  student  could 
call  up  a  format  or  replace  the  message  on  the  bottom  screen  with  the  initial 
menu,  depending  upon  the  particular  experimental  treatment.  This  procedure 
required  the  preparation  of  two  question  frames  for  what  would  ordinarily 
have  required  only  one.  Each  ordinary  question  frame  was  reconstituted  as 
a  pair  of  frames.  It  resulted  in  the  capability  to  measure  two  additional 
dependent  variables : 


4.  Decision  time.  This  was  measured  as  the  elapsed  time  from  the 
presentation  of  the  scenario  to  the  student's  pressing  of  the 
illegal  switch  action  button  (the  second  button) .  This  time  was 
recorded  on  the  student  record  as  the  elapsed  time  for  the  first 
question  frame  in  each  pair. 

5.  Performance  time.  This  was  measured  as  the  elapsed  time  from 
the  student's  pressing  the  illegal  switch  action  button  to  the 
end  of  the  overall  question  frame  as  seen  by  the  student.  This 
time  was  recorded  on  the  student  record  as  the  elapsed  time  for 
the  second  question  frame  in  each  pair. 


CONDUCT  OF  THE  VALIDATION  EFFORT 


The  Purpose  of  the  Project 

The  effort  which  was  undertaken  apparently  was  intended  to  begin  a 
program  of  research  into  the  training  implications  of  various  AFATDS  con¬ 
figurations  without  concern  for  validating  the  TTS  SIMCAP.  This  initial 
effort  was  conducted  largely  as  a  shake  down  or  debugging  of  the  equipment, 
facilities,  and  procedures  that  made  up  the  TTS  SIMCAP.  However,  the  effort 
was  intended  to  be  more  than  just  an  exercise  of  the  TTS  SIMCAP  since  three 
performance  treatments  were  developed  and  applied  within  an  experimental 
design. 

Three  groups  of  subjects  were  trained  in  four  different  tasks  performed 
by  ACC  operators.  Each  group  received  a  different  performance  condition: 

(1)  One  group  was  trained  to  fill  in  the  standard  mission  formats  used  in 
the  existing  TACFIRE  system,  (2)  one  group  used  the  same  formats  but  was 
also  provided  with  a  printed  job  aid  to  use  during  both  training  and  per¬ 
formance,  and  (3)  one  group  was  provided  with  specially  designed  menus  in 
place  of  the  conventional  formats  on  the  lower  screen. 

Method 

1.  Subjects.  Thirty-nine  (39)  subjects  initially  entered  the  project. 

Data  was  collected  from  only  34  subjects.  They  ranged  in  rank  from  E-l  to 
E-6  with  the  majority  having  a  rank  of  E-l.  None  of  the  subjects  had  had 
any  prior  TACFIRE  training,  but  all  were  artillerymen  representing  a  variety 
of  MOS. 

2.  Performance  conditions.  Each  subject  was  administered  one  of  three 
different  performance  conditions.  Each  subject  received  the  same  performance 
condition  in  both  training  and  testing. 

a.  Standard  TACFIRE  formats  without  any  job  aids.  These  formats 
require  the  operator  to  enter  information  into  the  appropriate 
blanks  in  the  format  on  the  screen  by  means  of  the  keyboard. 

The  blanks  are  labelled  with  abbreviations  which  designate  the 
kind  of  information  required. 
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b.  Standard  TACFIRE  formats  with  job  aids  similar  to  those  found 
in  standard  TACFIRE  manuals  (e.g.,  TM  11-7440-253-10-3)  except 
that  they  had  been  specifically  tailored  for  the  four  tasks 
selected  for  training  and  performance  evaluation. 

c.  A  menu  selection  system  which  in  most  instances  simply  required 
the  operator  to  move  the  cursor  to  his  choice  in  the  menu  and 
press  the  transmit  button.  Occasionally,  a  menu  would  request 
a  typed  entry. 

In  both  the  format  and  menu  conditions,  the  cursor  is  moved  from  one  field 
or  menu  choice  to  another  by  means  of  tabbing. 

3.  The  tasks.  Four  ACCO  tasks  were  selected  as  the  performance  vehicles 
for  the  project: 

a.  Build  an  ammunition  and  fire  unit  (AFU)  file.  This  is  reputed 
to  be  a  very  simple  task  consisting  of  but  one  format  line. 


b.  Create  an  on-call  or  fire  plan  target  list. 

c.  Initiate  a  fire  mission. 
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d.  Establish  a  fire  unit  in  the  AFU  file.  This  is  reputed  to  be 
one  of  the  most  difficult,  if  not  the  most  difficult  of  the 
TACFIRE  tasks.  This  task  is  performed  when  the  fire  units  are 
initially  setting  up.  Hap  coordinates  of  the  various  fire  units 
are  recorded  along  with  the  amount  and  type  of  ammunition,  type 
of  weapon  and  model,  meteorological  data,  and  zone  of  responsibility. 

4.  Training  procedures.  All  subjects  were  given  group  instruction  at  the 
beginning  of  training  on  what  a  format  or  menu  consisted  and  how  each  was 
used.  Different  performance  conditions  were  run  at  different  times,  so  the 
subjects  saw  only  the  one  condition  which  was  being  administered  to  them. 

Following  the  group  instruction  on  the  formats  and  menus,  subjects 
received  group  Instruction  on  the  physical  operation  of  the  ACCO  terminal. 

This  instruction  covered  such  points  as  the  need  to  reset  the  cursor  before 
sending  or  composing  a  message,  the  cursor  movement  buttons,  the  EOT 
(end-of-text)  key,  the  tab  key,  the  erase  key,  etc.  After  this  instruction, 
each  subject  was  allowed  approximately  eight  minutes  to  "play"  with  the 
buttons  on  the  console. 

All  subjects  in  all  performance  conditions  were  provided  with  a  Table 
of  Legal  Entries  to  use  during  training  and  testing.  These  tables  were  taken 
from  Field  Artillery  materials  to  provide  the  subjects  with  the  legal  entries 
for  some  of  the  format  and  menu  fields.  The  entries  were  for  weapon  and 
model,  ammunition,  and  target  types  and  subtypes. 
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Subjects  in  the  Aided  Format  condition  also  received  a  copy  of  the 
job  performance  aid  developed  for  this  condition.  A  copy  of  the  job  per¬ 
formance  aids  is  presented  in  Appendix  A. 

A  lesson  was  developed  for  each  of  the  four  tasks.  Each  lesson  was 
divided  into  three  section:  (1)  A  pretest  section,  (2)  an  instruction  and 
drill  section,  and  (3)  a  posttest  section. 

The  pretest  section  was  included  to  determine  how  well  a  subject  could 
perform  without  any  formal  practice.  The  question  frames  in  this  section 
did  not  provide  feedback  for  correct  responses.  If  the  subject  made  an 
error,  he  would  receive  the  message  "YOU  MADE  AN  ERROR"  and  nothing  more. 

The  instruction  frames  presented  informational  material  explaining  the 
use  of  various  mnemonics  (formats  and  menus),  what  the  various  options  stood 
for,  how  the  system  used  various  types  of  information,  and  so  on.  The  in¬ 
struction  frames  might  also  require  a  subject  to  enter  specified  information 
into  the  system,  but  the  information  was  not  placed  in  a  scenario  context. 

The  drill  frames  presented  the  subject  with  a  scenario  and  instructed  him 
to  fill  out  a  specific  format  field  or  to  make  a  menu  selection.  In  both 
types  of  frames,  feedback  was  given  only  for  incorrect  responses.  It  was 
partially  corrective  feedback  in  that  it  told  the  subject  what  the  correct 
response  should  have  been  but  did  not  explain  why;  that  is,  it  did  not  correct 
the  subject's  misunderstanding. 

The  posttest  section  of  each  lesson  contained  four  posttests.  If  any 
one  of  the  posttests  was  completed  correctly  on  the  first  trial,  the  subject 
terminated  the  lesson.  Otherwise,  the  subject  progressed  to  the  next  posttest. 
If  the  fourth  posttest  could  not  be  answered  correctly  after  the  first  trial, 
the  subject  was  transferred  back  to  the  beginning  of  the  main  lesson  section. 

He  was  required  to  repeat  the  entire  lesson  before  attempting  the  posttest 
again. 

The  posttests  used  the  "illegal  switch  action"  button  to  separate  de¬ 
cision  time  from  performance  time  as  previously  described.  At  the  beginning 
of  a  frame,  the  subject  was  presented  with  a  scenario.  In  some  frames  the 
subject  would  be  instructed  as  to  what  format  or  meny  to  call  up.  More  than 
one  format  field  or  more  than  one  menu  were  always  required  to  respond  to  a 
scenario.  If  the  subject's  response  was  incorrect,  he  would  receive  a  message 
like  "YOU  MADE  AN  ERROR,  TRY  AGAIN."  The  subject  could  not  leave  the  frame 
until  the  correct  response  was  made. 

5.  Experimental  procedures.  The  experimental  effort  was  conducted  over  a 
five  week  period.  On  the  first  day  of  each  week  a  new  group  of  subjects 
arrived.  In  the  initial  session  with  each  group  of  subjects  they  were  oriented 
to  the  TACFIRE  system  (what  it  is,  its  mission,  and  so  on)  and  they  were 
oriented  to  the  SIMCAP  (a  performance  test  bed  for  alternative  AFATDS  and  a 
vehicle  for  AFATDS  related  training  and  performance  research).  The  group 
instruction  on  formats  or  menus  and  operation  of  the  terminal  followed  the 


orientation.  Various  administrative  activities  were  conducted  during  this 
first  day  and  subjects  were  administered  a  typing  test  and  a  reading  com¬ 
prehension  t  €Bt .  Subjects  then  began  the  training  program.  However,  no 
pretests  or  posttest  were  administered  during  the  first  two  weeks. 

Each  subject  proceeded  through  the  pretest,  training,  and  posttest  at 
his  own  rate.  Subjects  proceeded  to  each  subsequent  task  as  soon  as  they 
finished  the  preceding  task. 

Results 

Although  the  effort  was  designed  as  an  experiment,  many  components  of 
the  project  were  not  in  place  at  the  beginning  of  the  effort.  For  instance, 
pretests  and  posttests  were  not  introduced  until  the  third  week.  The  PLANIT 
lesson  programs  still  had  many  errors  in  them.  These  errors  frequently  led 
to  subjects  (1)  being  held  in  a  lesson  frame  even  though  their  responses  were 
correct,  (2)  being  advanced  to  the  next  lesson  frame  even  though  their  re¬ 
sponses  were  incorrect,  and  (3)  being  presented  with  Incomplete  or  erroneous 
scenario  information.  The  researchers  spent  much  of  their  time  responding 
to  the  occurrence  of  these  errors  and  correcting  the  programming  that  pro¬ 
duced  them. 

The  administrative  difficulties  described  above  greatly  interfered  with 
the  subjects'  progress  during  the  first  half  of  the  project.  No  subject  was 
able  to  attempt  all  four  tasks  until  the  fourth  week  of  the  project.  And  no 
subject  completed  all  four  tasks  during  the  entire  project.  Consequently, 
complete  data  was  not  collected  for  any  of  the  three  performance  conditions. 

At  the  end  of  the  week  they  were  released  regardless  of  how  far  they  had 
progressed  on  the  four  tasks.  No  more  than  nine  (9)  subjects  completed  any 
one  task  in  any  of  the  performance  conditions.  Many  tasks  in  some  performance 
conditions  were  completed  by  only  two  (2),  three  (3),  four  (4),  or  five  (5) 
subjects.  The  changing  conditions  during  the  project  and  the  very  few  number 
of  subjects  who  completed  many  of  the  task/condition  treatments  mitigated 
against  any  statistical  analysis  of  the  results. 


REVIEW  OF  THE  RATIONALES  UNDERLYING  THE  SIMCAP  DESIGN 


Concept  for  an  AFATDS  SIMCAP 

The  TTS  SIMCAP  appears  to  have  been  conceptualized  simply  as  a  context 
for  training  and  performance  research  with  the  existing  TACFIRE  system.  The 
emphasis  on  "realism"  to  TACFIRE  precludes  investigations  of  radically 
different  AFATDS  alternatives.  It  would  have  been  more  useful  to  conceptual¬ 
ize  the  SIMCAP  as  representing  the  behaviorally  significant  software-generated 
interface  characteristics  of  a  population  of  current  and  future  AFATDS.  This 
would  have  led  to  the  identification  and  analysis  of  the  necessary  functional 
characteristics  of  any  and  all  AFATDS  and  the  early  identification  of  ad¬ 
vanced  equipment  technologies  for  performing  these  functions.  In  this  way 
the  SIMCAP  could  have  been  used  as  a  way  of  anticipating  AFATDS  alternatives 
rather  than  being  locked  into  the  existing  TACFIRE. 

An  AFATDS  is  basically  an  information  processing  system.  In  its  crudest 
form,  all  the  information  processing  functions  of  an  AFATDS  are  performed  by 
human  beings.  As  the  systems  become  more  and  more  sophisticated,  equipment 
is  introduced  to  perform  certain  of  these  functions.  Thus,  the  commander 
of  a  Roman  ballista  unit  may  have  used  pebbles  to  keep  track  of  how  many 
rounds  each  of  his  weapons  still  had  available.  He  may  have  scratched 
out  a  representation  of  the  battlefield  on  the  dirt  in  front  of  him,  showing 
the  locations  of  his  weapons  and  the  location  of  potential  targets.  These 
are  techniques  for  supplementing  and  enhancing  his  own  internal  information 
processing.  They  constitute  the  equipment  components  of  a  very  crude  AFATDS. 
The  TACFIRE  system  is  a  much  more  sophisticated  method  for  enhancing  a  com¬ 
mander's  own  internal  Information  processing.  But  the  information  processing 
functions  performed  in  each  of  these  instances  are  essentially  the  same. 

Hence,  it  would  appear  that  the  general  pattern  of  information  processing 
functions  required  to  coordinate  artillery  fires  is  a  common  component  of 
all  conceivable  AFATDS — past,  present,  and  future. 

Man  would  also  appear  to  be  a  common  component  of  all  conceivable 
AFATDS,  although  man's  role  in  the  system  may  become  more  and  more  circum¬ 
scribed  as  the  equipment  becomes  more  and  more  sophisticated.  As  the  systems 
become  more  sophisticated,  the  equipment  takes  over  more  of  the  information 
processing  functions. 

As  equipment  technology  advances ,  equipment  can  be  designed  to  perform 
some  information  processing  functions  more  effectively  than  man.  In  fact, 
the  basic  problem  faced  by  system  designers  is  to  allocate  information 
processing  functions  best  performed  by  equipment  to  equipment  and  to  allocate 
information  processing  functions  best  performed  by  man  to  man  and  to  design 
an  optimum  information  processing  interface  to  join  the  human  and  equipment 
components  of  the  system.  Of  these  two  types  of  components,  man  is  the  more 
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constant,  the  less  amenable  to  changes  in  basic  capabilities.  Hence,  the 
rest  of  the  system  components  and  the  interfaces  should  be  designed  to  serve 
man.  An  optimum  equipment  interface  should  provide  man  with  information 
displays  formatted  to  fit  his  information  processing  requirements  and  the 
controls  should  be  designed  to  accept  the  natural  formats  of  man's  information 
outputs.  It  follows,  then,  that  one  major  information  base  for  designing  an 
AFATDS  or  an  AFATDS  SIMCAP  would  be  a  catalog  of  man's  capabilities  for  per¬ 
forming  the  various  information  processing  functions  required  by  an  AFATDS. 

All  too  often  system  designs  are  developed  in  the  inverse  manner: 

Equipment  is  designed  on  the  basis  of  existing  equipment  technology  and  man 
is  forced  to  fit  the  equipment  demands.  System  design  should  not  proceed  by 
putting  man  into  the  loop  as  an  afterthought.  Initially,  man  is  the  entire 
loop.  Equipment  should  be  introduced  only  to  relieve  man  of  responsibility 
for  those  segments  of  the  loop  that  equipment  can  perform  better.  But  before 
we  can  know  whether  or  not  to  assign  a  segment  to  equipment,  we  first  have  to 
identify  all  the  functional  segments  in  the  loop  and  determine  man's  capability 
to  perform  each  one. 

Components  of  an  AFATDS  SIMCAP 


We  have  identified  three  basic  components  for  designing  an  AFATDS  SIMCAP: 

1.  An  identification  of  the  general  information  processing  function 
required  to  coordinate  artillery  fires. 

2.  A  catalog  of  man's  capabilities  for  performing  each  kind  of 
information  processing  function. 

3.  An  identification  of  the  functional  characteristics  of  the 
information  processing  interface  between  the  human  and  equipment 
components  of  the  system.  Our  concern  here  is  with  specifying 
the  functional  characteristics  of  display  and  control  formats 
and  contents  that  meet  the  information  processing  characteristics 
of  human  beings. 

None  of  these  components  was  included  in  the  TTS  SIMCAP. 

Artillery  units  and  AFATDS  operate  in  real  combat  environments  and  real 
combat  situations.  The  significant  characteristics  of  these  environments  and 
situations  need  to  be  identified  so  that  they  can  be  properly  represented  in 
SIMCAP  scenarios.  In  addition,  the  characteristics  that  define  system 
effectiveness  in  these  environments  need  to  be  identified.  How  else  are  we 
to  judge  performance  in  a  given  scenario?  Now  we  can  add  a  fourth  component 
to  our  SIMCAP: 


4.  A  specification  of  the  more  likely  characteristics  of  the  real 
combat  environments  and  situations  in  which  AFATDS  systems  will 
operate  and  a  specification  of  the  characteristics  of  effective 
system  performance  in  those  environments  and  situations. 
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No  mention  is  made  in  the  TTS  SIMCAP  regarding  the  source  or  development 
or  representativeness  of  the  scenarios  used  in  training  and  testing. 

The  primary  function  of  a  SIMCAP  is  to  assess  human  performance.  In 
order  to  assess  human  performance,  the  performance  must  be  measured  and 
valued.  The  characteristics  or  consequences  of  human  performance  that  we 
observe  and  record  and  analyze  constitute  the  dependent  variables  of  the 
SIMCAP.  But  measures  which  do  not  possess  known  significance  cannot  be 
valued.  In  an  AFATDS,  we  are  only  concerned  with  measuring  those  charac¬ 
teristics  of  human  performance  which  can  be  shown  to  contribute  to  or  de¬ 
tract  from  system  effectiveness.  The  only  way  to  establish  the  significance 
of  such  measures  is  to  relate  them  to  the  characteristics  of  system  effec¬ 
tiveness  in  combat  environment  and  situations.  The  operator  performance 
measures  can  be  related  to  characteristics  of  system  effectiveness  in  either 
of  two  ways:  (1)  They  can  be  derived  from  the  characteristics  of  system 
effectiveness  or  (2)  they  can  be  shown  experimentally  to  contribute  to 
characteristics  of  system  effectiveness — or  both.  We  now  have  a  requirement 
for  another  component  for  an  AFATDS  SIMCAP: 

5.  A  set  of  dependent  variables  (operator  performance  measures) 

for  measuring  and  valuing  human  performance  in  the  AFATDS  which 
are  either  derived  from  or  experimentally  related  to  the  charac¬ 
teristics  of  system  effectiveness  in  combat  environments  and 
situations . 

The  dependent  variables  specified  for  the  TTS  SIMCAP  were  apparently  selected 
simply  because  they  were  available  by  the  PLANIT  programming  language.  These 
dependent  variables  are  indeed  measures  of  human  performance,  but  there  is  no 
way  of  ascribing  value  to  differences  among  these  measures.  Is  one  kind  of 
error  as  damaging  to  system  effectiveness  as  another  kind  of  error?  Is  a 
given  Improvement  in  operator  response  time  worthwhile  in  terms  of  its  cost 
and  its  effect  on  system  effectiveness?  Without  a  system  for  valuing  changes 
in  human  performance,  we  could  waste  research  resources  in  trivial  efforts. 

Finally,  we  arrive  at  the  equipment  components  of  a  SIMCAP.  Clearly, 
a  SIMCAP  will  require  display  and  control  consoles  for  operators  and  com¬ 
manders.  Such  consoles  should  be  capable  of  simulating  the  Information 
processing  characteristics  of  the  man-machine  interface  in  whatever  ways 
as  are  suggested  by  existing  and  forseeable  equipment  technologies.  What 
kind  of  Information  content  is  needed  by  the  operator  and  at  what  level  of 
abstraction?  How  should  such  information  be  represented  and  formatted? 

What  kind  of  information  content  is  produced  by  the  operator  and  how  does 
he  represent  and  format  it?  We  need  displays  and  controls  that  are  flexible 
enough  to  allow  us  to  alter  the  characteristics  of  the  information  exchange 
at  the  man-machine  interface.  The  physical  displays  and  controls  that  make 
up  the  operator/commander  consoles  constitute  the  sixth  component  for  a 
SIMCAP: 
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6.  Operator/commander  consoles  consisting  of  displays  and  controls 
whose  Information  processing  characteristics  can  be  modified  to 
represent  the  potential  characteristics  which  might  be  provided 
by  developing  equipment  technologies. 

The  TTS  SIMCAP  adopted  the  consoles  and  their  associated  displays  and  con¬ 
trols  provided  by  the  first  generation  AFATDS — the  TACFIRE  system.  Such  a 
choice  provides  very  little  capability  for  simulating  future  systems  and  the 
potential  of  future  equipment  technologies.  For  instance,  the  existing 
TACFIRE  ACC  does  not  provide  a  means  for  representing  data  graphically  or 
for  allowing  the  operator  to  respond  by  using  a  light  pen  to  indicate  a 
location  on  the  screen.  This  technology  exists  now  but  could  not  be  tested 
on  the  TTS  SIMCAP.  It  is  certainly  reasonable  to  believe  that  graphic  repre¬ 
sentations  are  much  closer  to  the  manner  in  which  battlefield  information 
is  naturally  represented  by  human  beings  in  their  own  internal  information 
processing.  But  the  TTS  SIMCAP  is  not  capable  of  supporting  such  research. 

The  equipment  components  of  a  SIMCAP  must  also  include  ways  of  scheduling 
and  controlling  information  displays  and  ways  of  recording  operator/commander 
performance.  The  physical  SIMCAP  must  clearly  be  designed  around  a  computer. 
The  computer  should  be  readily  programmable  and  expandable  to  meet  future 
requirements.  There  are  many  commercially  available  microcomputers  on  the 
market  now  that  meet  these  requirements.  The  final  component  for  a  SIMCAP 
is  a  computer: 

7.  A  readily  programmable  and  expandable  computer  for  scheduling 
and  controlling  information  flow  in  the  SIMCAP  and  for  recording 
operator /commander  performance. 

Apparently,  the  computer  used  in  the  TACFIRE  with  the  enhanced  memory  provided 
by  the  TTS  and  the  PLANIT  language  was  chosen  to  use  in  the  TTS  SIMCAP  simply 
because  it  was  available.  PLANIT  is  not  a  commonly  used  programming  language. 
And  the  TACFIRE  computer  represents  an  outmoded  computer  technology  by  today's 
commercial  standards.  A  single  double  sided,  double  density  floppy  disk 
drive  matches  or  exceeds  the  memory  capacity  of  the  TTS  computer  at  a 
miniscule  fraction  of  the  cost.  In  addition,  the  TTS  is  not  readily  accessible 
for  research  use  and  it  certainly  could  not  be  relocated  for  research  pur¬ 
poses  alone. 

Applications 

1.  Training  design.  The  training  design  used  in  the  TTS  SIMCAP  validation 
project  does  not  represent  an  application  of  the  sophisticated  training 
technology  available  today.  It  is  task  based  rather  than  skill  based. 
Consequently,  it  would  have  been  difficult  even  if  the  project  had  been 
successfully  completed  to  ascribe  differences  between  the  three  performance 
condition  groups  to  the  performance  conditions  themselves  or  to  differences 
in  instruction.  For  instance,  since  all  practice  was  performed  on  the  TTS 
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equipment  subjects  in  the  format  conditions  engaged  in  constructed  responses 
exclusively  whereas  subjects  in  the  menu  condition  engaged  principally  in 
recognition  responses.  These  are  two  response  modes  that  are  known  to  have 
different  effects  on  learning,  retention,  and  performance.  Recalling 
(reciting)  the  content  of  formats  or  menus  could  have  been  practiced  as 
separate  skills  under  similar  conditions  before  beginning  whole  task  practice 
on  the  simulator.  This  would  have  greatly  diminished  the  differences  in 
practice  conditions  for  the  two  kinds  of  performance  conditions  and  it  also 
would  have  made  training  more  efficient. 

The  task  based  approach  to  training  was  not  efficient  with  regard  to 
use  of  the  TTS.  Each  student  used  a  station  on  the  TTS  for  all  the  practice 
in  which  he  engaged  to  learn  the  tasks.  If  the  tasks  had  been  analyzed  into 
subordinate  skills,  practice  on  most  of  the  skills  could  have  been  done  on 
paper  simulations.  Students  would  not  have  begun  whole  task  practice  on  the 
TTS  until  they  had  mastered  the  subordinate  skills.  This  would  have  greatly 
reduced  their  need  for  whole  task  practice  and,  consequently,  would  have 
reduced  the  demand  for  expensive  TTS  equipment. 

2.  TTS  SIMCAP  validation.  The  selection  of  the  TTS  as  the  vehicle  for  the 
SIMCAP  confounded  the  design  of  a  project  for  validating  the  SIMCAP.  If 
the  SIMCAP  configuration  is  identical  to  the  existing  TACFIRE  configuration — 
indeed  is  the  same  equipment,  then  there  is  nothing  to  validate.  The  predicto 
conditions  are  the  criterion  conditions:  Hence,  there  is  nothing  to  be  pre¬ 
dicted.  Under  these  conditions,  the  TACFIRE  cannot  be  used  as  a  representa¬ 
tive  of  the  population  of  existing  and  future  AFATDS  to  use  as  the  criterion 
condition  in  a  validation  effort.  The  project  that  was  conducted  did  not 
compare  the  inferences  drawn  from  performance  on  the  TTS  SIMCAP  with  in¬ 
ferences  from  similar  performances  on  the  TACFIRE.  It  would  have  made  no 
sense  to  have  done  so,  yet  not  doing  so  fails  to  validate  the  TTS  SIMCAP. 
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1  TEP  FIELD 

ACTION 

STEP  FIELD 

ACTION 

if  desired,  enter  shells  to 
be  used  against  listed  tar¬ 
gets.  If  shell  entered  only 
in  first  subfield,  it  will  be 
used  for  initial  and  subse¬ 
quent  volleys.  Refer  to 
legal  entries  for  ammunition 
(Table  B,  Page  2).  Required 
for  non-HE  shells. 

Default  •  HE. 

—  Initial  volley 

—  Subsequent  volleys 


If  desired,  enter  fuses  to  be 
used  against  listed  targets. 

If  fuze  entered  only  in  first 
subfield,  it  will  be  used  for 
initial  and  subsequent  volleys. 
Refer  to  legal  entries  for 
ammunition  (Table  B,  Page  2). 
Required  for  non-HE  shells 

—  Ini t ial  volley 

—  Subsequent  volleys 
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REFERENCE 
STEP  FIELD 


ACTION 


1  NNFPilNST  Call  up  NNFP ; INST  format 

2  PLAN  Enter  plan  name 


3  FPTCT 


4  TGTS 


S  PRIOR 


Enter  l  to  specify  that  tar¬ 
gets  entered  in  Step  4  are 
designated  as  scheduled 
targets. 

Enter  target  Humberts) 

Enter  target  priority  nvmber 
to  be  used  in  scheduling 
targe's  (1  to  4) .  First 
priority  »  >.  Default  »  4. 


If  high  angle  required,  enter 
angle  of  fire.  Legal  entries 
are: 


high 

lew  (default) 
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CREATE  AN  ONCALL  OR  FIRE  FLAN  TARGET  LIST 

<  C  ONT I NU  E  D  > 


HNFP ; INST i PLAN: - ; FPTCT : - ; ONCALl : - ; DELETE  :  - ; 

TCTS: .  . 

PRIOR : - ;  PHASE  - ;  GROUP  : - ;  SERIES  :  - . /  -  ; 

UFFES:-/-/-/--/ - - —  / - - 

IFF :  i  VOL :  — ;  SH: - / - ;FZ: - / - ;  ANGLE: - J 


“  REFERENCE  '  REFERENCE 

TEP  FIELD  ACTION  STEP  FIELD  ACTION 


l  Schedule  the  targets  by  specifying  either^ 
phase( s)  or  H-hour  (H  field)  but  not  both’ 

B  I 

PHASE  Specify  phase(s)  targets  are 

to  be  scheduled.  If  not 
specified,  targets  scheduled 
during  any  phase. 


r 


RASE:-,-,-,-; 


Enter  phase  (1  to  4)  if 
first  phase  target  is  to  be 
f  i  red 

Enter  phase  <2  to  4)  if 
second  phase  target  is  to 
be  fired 

Enter  phase  <3  or  4)  if 
third  phase  target  is  to  be 
fired 

Enter  phase  4  if  fourth 
phase  target  is  to  be  fired 


7  UFFES  I!  desired,  enter  logical  su 

scriber  name  of  fire  units  t 
be  used  in  tire  plan  against 
target 

- —  Section  number 

r- - Platoon  number 

%  * 

. . . -Battery 

- Battalion  or  division 

— Regiment,  brigade,  or 
division 

UFFES:-/-/-/  —  /-  —  , 

I  OPTIONAL:  Perform  only  if  changes  in 
desired  effects  or  number  of  volleys  in 
attack  method  table  are  required,  or  it 
non-HE  shells  are  used.  (Use  VOL  tor 
non-HE  shells.) 
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EFF 

Enter  time  relative  to  H-hour 

that  target(s)  are  to  be 

fired  onUO  to  999).  Enter  ♦ 

and  number  of  minutes  (or  after 

H-hour;  enter  -  and  number  of  VOL 

minutes  for  before  H-hour  j 


Enter  percent  (0  to  »*%>  of 
desired  effects  of  attack 
method  for  targets.  Do  not 
use  with  VOL 

Enter  desired  number  of  vol¬ 
leys  (0  to  99).  Required 
•ntry  for  non-KE  shells.  Do 
not  use  with  EFF. 
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CREATE  AM  OMC  ALL  OR  FIRE  PLAN  TARGET  LIST 

<  COMT  I MU ED  > 


HNFP ; INST ; PLAN: - ; FPTCT : - ; ONCALt : - ;DELETE : - ; 
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PRIOR:-;  PHASE: . . . ;  CROUP: . ;  SERIES: . 
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STEP  FIELD 


ACTION 


y  SH 


If  desired,  enter  shells  to 
be  used  against  listed 
targets.  If  shell  entered 
only  in  first  subfield,  it 
will  be  used  for  initial  and 
subsequent  volleys.  Refer  to 
legal  entries  for  aaaunition 
(Table  B,  Page  2).  Required 
for  rion-HE  shells. 

Default  -  HE. 


11  ANCLE  If  high  angle  is  required 

enter  angle  of  (ire.  Leg 
entries  are: 

HICH  *  high 

LOW  »  low  (default) 


Initial  volley 


1  SH: - 1 


Subsequent  volleys 
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If  desired,  enter  fuses  to  be 
used  against  listed  targets. 
If  fuse  entered  only  in  first 
subfield,  it  will  be  used  for 
initial  and  subsequent  vol¬ 
leys.  Refer  to  legal  entries 
for  anaunition  (Table  B, 

Page  2).  Required  for  non-HE 
shel Is. 


Initial  volley 


•Subsequent  volleys 
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SPHERE  :  -  ;  DIR - /--;DIST: - .SHIFT: -/ - /-/ - 1 -I - ;  ASF  : - / - ; 

AUF  :  -  - ;TYP1 :  - . / . ;00P: - SIZE - / - ;  ATT: - ; 
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UFFE: - ,  —  /  —  /  —  /  —  / - ;SH: - / - ;  FZ  : - / - ,  LOT:  EFF: --  ; 

VOL  CMC  :  -  ;  EON:  -  ;  RAT:  -  ;MIS  :  -  ;OPT : ;  PR  I :  —  ;  ASNFPF :  - ;  BD:  -  —  . - J 
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FIELD  ACTION 
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STEP  FIELD  ACTION 


FM;RFAF  Request  FH ; RFAF  format 

CORD  Entar  coordinatas  and  altituda 

to  specify  target  location. 

Usa  short  coordinatas  if  in 
HAP  MOD. 


4  TYPE  Entar  target  type/subtype  it 

given.  Refer  to  legal  entri 
for  target  type/subtype 
(Table  C,  Page  7).  Default 
PERS/UNK 


Easting  <0  to 
77777?) 

Northing  (0  to 
11000000) 

A1 tituda  0  to 
1999  maters ) . 
Default  s  ♦ 


I - / 


DIR  Enter  the  observer  to  target 

di raet ion . 


Observer  to  target  direction 
(0  to  4377  mils) 

Do  not  make  entry.  (This 
field  is  for  gun-target 
direction. ) 


- Type 

*  » 

| - Subtype 

TYPE: . / . ; 

5  DO?  If  personnel  try  out  target, 

enter  degree  of  protection  i 
given.  Default  ■  PRUC .  Leg 
entries  include: 


FIRST 

SUBSEOUE 

VOLLEY 

VOLLEY 

PRAND 

- 

Half  prone, 
halt  standing 

All  pron 

PRONE 

a 

Prone , 

Prone 

PRUC 

a 

Prone , 

Dug  In 

PROVER 

a 

Prone , 

Under 

overhead 

eover 

DUC  IN 

a 

Dug  In, 

Dug  In 

COVER 

a 

Under 

Under 

overhead 

overhead 

eover 
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UP  PE:-/-/-/--/ .-/-/-  /  —  / ;SH: / ;  FZ : - / - ,  LOT :-/-/-,  EFF  ; 
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STEP  PIBLO 


ACTION 
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ACTION 


For  circular  target,  enter 
target  radio*  (first  aubfiald 
only).  Dalaolt  ■  100  meter 
radios . 

For  rectangular  target,  enter 
targat  length  (first  subfield) 
and  width  (second  subfield). 
ATT  (Step  7)  is  also  required 
for  rectangular  target. 

—  Radius  or  length  (0  to  »»»! 

■stars) 

—  Width  (0  to  9779  actors) 


10  CONT 


Enter  method  of  control  and 
fire 

—  Enter  method  of  control. 
Default  •  VR.  Legal  entrie 


VR  *  when  ready 
AMC  ■  at  ay  command 
CNO  ■  cannot  observe 
DNL  a  do  not  load 

•Enter  method  of  fire. 
Default  »  AF.  Legal  entri* 


Enter  altitude  (In  mils)  with 
rectangular  site  targets  <0  to 
4177) 

Specify  number  of  target  ele¬ 
ments  (I  to  7977)  It  available 

Enter  method  of  engagement 

-Enter  method  of  tire. 

Default  ■  LOW.  Legal  entries 


AF  ■  adjust  fire 
FFE  *  tire  for  effect 
RFFE  »  repeat  Lire  for 
effect 

The  only  combination  net 
legal  is  DNL/ AF 


NICK  •  high  angle 
LOW  ■  lew  angle 
DEST  ■  destruction 

-Enter  mettled  ef  attack. 
Default  ■  (blank).  Legal 
entries  are: 


DC  ■  danger  close 
REC  a  registration 
TOT  ■  time  en  target 


INITI ATE 


E  MISSION  <  C  ONT I NUED  > 


FM ; RF  AF : - ; MYEFF : ~ ; TGT . - ;  KNPT : - - ; CORD : . I . I - .Cl:---, 

SPHERE  : - ; DIR : - / ; DIST: - ;  SHIFT:  -  / - l-l - /-/ - ;ASF  :— / - ; 

AUF  - ; TYPE  . I - ;DOP: - .SIZE - / - ;  ATT: - ; 

STB - ;RV: ;  L  AS  : - /  -  ;TOT  ;ME : - / --- ;  CONT: - / - ;  ZF  :  —  /-; 

UFFE: - ,-i-i-i--i jSH: / ;FZ - / - ; LOT. -/-/-; EFF: -- ; 

VOL : -- ;OB : ; CHC : - ; EOM: - ; RAT: - ;MI S : - ;OPT: - ; PRI : - ; ASNFPF : - ; BD: --- . - I 


REFERENCE 

FIELD  ACTION 


UFFE  II  desired,  enter  logical  sub-  | 
scrlbsr  nano  tor  firo  units 
(up  to  2)  to  (iro  (or  offset. 
Use  battalion  nano  if  massed 
fires  of  battalion  fire  units 
desired.  If  battalion  name 
used,  enter  VOL  to  specify 
number  of  volleys  per  fire 
unit.  Default  •  computer 
selected 


First  fire  unit 

—  Sec  1 1  on 

—  Platoon 


■>  K 

;  FFE 


Battery 


Battalion 

Regiment  or  Division 


/-/-/- 


.s 

1 


SH 


If  desired,  enter  shell  to  be 
used  for  initial  volley  of  FFE 
(first  subfield)  and  shells  for 
subsequent  volleys  of  FFE 
(second  subfield).  Default  • 
computer  selected  HE  munitions. 
Refer  to  legal  entries  for 
ammunition  (Table  I,  Page  2) 


r.  For  HE  and  Chemical  (smoke  or 

jS  VP),  specify  HE- /SMI  or  HE-/  I 

IMA.  Note:  If  ehemioal  shell  1 
type  Is  entered,  F2  and  VOL 
y  ,  must  also  be  specified 


REFERENCE 

STEP  FIELD  ACTION 


If  only  first  subfield  is 
entered,  subsequent  volleys 
will  use  same  shell  as  entered 
for  initial  volley. 

————Initial  volley.  Default  * 
computer  solution 

r Subsequent  volleys.* 

Default  ■  projectile  used 
initially 

SH ; 

13  FZ  If  desired,  enter  fuse  to  be 

used  for  first  and  subsequent 
volleys  during  fire  for  effect 
Refer  to  legal  entries  for 
ammunition  (Table  B,' Page  2) 

For  non-HE  ammunition  (eicept 
illumination),  shell  and  fuse 
must  be  entered.  Enter  VOL 
if  more  than  one  volley  desired 

Initial  volley.  Default  a 
computer  selution 

Subsequent  volleys  Defauf 
fuse  used  in  initial  volley 

FZ. - / - ; 
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FN; RFAF : - ;MYEFF  :  -  -  ;TGT : . ;  KNPT : -- ;  CORD: - / - / - ;GZ:--- 

SPHERE  :  - ;  DIR: - /--;D!3T - ;  SHIFT:-/ - /-/ - /-/ - .ASF: - / - ; 

AUF  —  / - .TYPE  : - / - ;DOP: . SIZE  : - / - ;  ATT - 

STR : - ; RV : - ;LAS - /- ,TOT:  .ME  : - / - ;  CONT: - / - ; ZF : -- /  - 

VFFE - —  / - ;  SH : - / - ; FZ  : - / - ; LOT EFF : 

VOl :  —  ;01 :  — ;  CMC:  -  *,EOM :  - ; RAT :  -  ;MIS :  - ;OPT:  ; PRl ;  ASHFPF  : - ;BD: . - i 


V  SJEP 


REFERENCE 

FIELD 


ACTION 


OPTIONAL:  Pit (tra  only  il  changes  in 

desired  aflooti  or  nonbars  ol  volleys  in 
attack  table  art  required.  DO  NOT  enter 
data  Into  both  EFF  and  VOL  fields. 

EFF  Enter  desired  effects  (1  to  99 

percent)  if  given.  This  entry 
will  override  desired  effects 
for  this  type  target  in  attack 
■ethod  table,  and  commander's 
attaok  criteria  entered. 

VOL  Enter  number  of  desired  volleys 

tl  to  99)  if  given.  This  entry 
will  override  data  in  attack 
method  table,  and  commander's 
attack  criteria.  Do  not  enter 
it  EFF  is  used.  It  chemical 
munitions  are  specified,  enter 
VOL  if  default  (1  vol)  is  not 
desired. 


£'5  OB 


fU  CMC 

L# 


.7  PR1 


Enter  observer  number  <1  to  99) 

If  given. 

If  desired,  enter  desired  charge 
<1  to  •) .  Default  •  computer 

selected 

If  desired,  enter  fire  mission 
priority  designator.  Enter  1  to 
specify  Category  A  (Urgent),  2 
to  specify  Category  8  (Priority), 
if  left  blank,  specifies  Cate¬ 
gory  C  (normal).  Default  ■ 
computer  determined. 
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FIRE  UNIT  IN  THE  AFU 


AFU ; UPDATE; PLAN: - . ;  FU: - ;  VPN: . -;HODEL: . ,MSN - , 

CORO: - / - / . ;CZ: - ;  SPHERE  :  -  ;  APPL  ST:  -  ;  ZONE  - - ; 

VSTR:  -  - ;  AX - - ,  Dt : - iTIHEI': - , UREINF /  —  / - ; F5P - ; 

MAIRNC  - .-/ . . . I - ,-/ - ;MINRNG  : - ;  TRAVLR : - / - 

NAXEl : - i MAI ATI SUSRTE BPLOC : - / / - / ; FULAT BKUP : - 

DELETE: - ; it: -;*5: - ; READT : - ; OUTTIL : — PTEMP: - ;DTC J 


REFERENCE 

FIELD 


ACTION 


REFERENCE 
STEP  FIELD 


ACTION 


1  AFU ; UPDATE  Call  up  AFU ; UPDATE  foraat 

®  -FLAN  Enter  lira  plan  naai.  Us* 

ALL  if  data  applit*  to  all 
lira  plana.  Default  a 
>'!  eurrant  situation 

(FU  Enter  logical  subscriber 

naa*  of  new  fire  unit  or 
fire  unit  to  be  updated 

>  -  Sect  ion  nuaber 

...  ■...i..  -  Platoon  nuaber 

L 

■  ■■■  •  Battery 


4  MSN 


Battalion  or  division 


Regiaent,  brigade  or 


''FU:-/-/-/  — /— 
>  VPN 

d 


r  dt  visi< 


7  CORD 


H 

r  MODEL 


Enter  weapon  type  used  by 
fire  unit.  If  fir*  unit 
uses  ala  of  types,  establish 
new  fir*  unit  for  each  weap¬ 
on  type.  Refer  to  legal 
entries  for  weapon  and 
aodol  (Table  A,  Pago  1) 

Enter  weapon  aodel  nuaber. 
Refer  to  legl  entries  for 
weapon  and  aodel  (Table  A,  ( 
Pag*  1) 


CORD:' 


t  APPL 


Enter  aission  of  fir*  unit 
Legal  entries  are: 

CS  ■  general  support 
DS  *  direct  support 
CSR  »  general  support 
re  inforcing 
R  m  r  e  i  n  t  o  r  c  i-rvg 

Enter  grid  coordinates  of 
unit.  Us*  short  coordinat1 
if  located  within  MAP  MOD: 
otherwise,  us*  long  coordi¬ 
nates. 

__________ _  Easting  (0  to 

79977?) 

__________  Northing  (0  to 

11000000) 


Altitude  (♦  to 
7979  actors). 
Default  ■  ♦ 


Enter  aaaunition  type 
authorised  tor  use  by  tire 
unit.  Enter  any  eoabina- 
t ten  of  HE,  CM,  or  NU.  It 
all  types  are  authorised, 
enter  AL.  Legal  entries 


NE  ■  high  eiplosii 
CH  *  cheaieal 
NU  ■  nuoioar 


establish  a  fire  unit  in  the  afu  file 

(CONTINUED) 


AFU; UPDATE;  PLAN: - ;FU-/-/-/--/~-  ,VPN: . ; MODEL  : - MSN  ---  , 

CORO; - / - / - ;GZ: - ; SPHERE : - ; APPL ST: - ;  ZONE  : - ; 

VSTR :  -  - ;  AZ  - - ;DF - ;TIME#:  —  ;UREINF ; -/-/-/  —  / - ; FSP -  ; 

MAZRNC  :  - / . . . .-/ . . . . . ;MINRNC; . . TRAVLR  : - / - 

HAUL ; - ;  HAXRTE  SUSRTE  BPLOC ;  FULAT; ;  BKUP :  - 

DELETE: - ;RT: - ;RS: - ; READY : - ; OUTTIl : FTEMP : - ; DTG . - - / - - / - - j 


'  REFERENCE 
FIELD 


->  ZONE 


fl  WSTR 


13  DF 


ACTION 


Enter  type  ol  sight  used  by 
firs  anit.  Ligil  entries 


1  -  3200  NIL  sight 

2  ■  4400  HIL  sight 

(default) 

3  ■  bearing  sight 

Enter  naee  of  cone  of 
responsibility  as  estabished 
in  SFRT;ZNE 

Enter  number  of  tubes  <1  to 
99) 

Enter  asiauth  from  grid 
north  on  which  fire  unit  is 
laid  (0  to  4393  mils) 

Enter  defleotion  when  fire 
unit  is  pointing  on  original 
asiauth  of  fire.  Common 
defleotlons  are: 


WEAPON 


10SNM  (M101A1) 


105MM  (Hi 02) 


I0SHH  (Ml 01 ) 


13SMM  (MHIHAl) 


DEFLECTION 
IN  MILS 


REFERENCE 
STEP  FIELD 


ACTION 


WEAPON 


1SSMM  (Ml 09 ) 


DEFLECTION 
IN  MILS 


14  TIMER 


IS  URE1NF 


SIN  (M110,  Ml  IS ) *•  3200 

17SHM  (Ml 07 )  3200 

Enter  fire  unit  nuclear 
response  time.  No  entry 
required  for  nonnuclear  fir 
units  (0  to  999  minutes) 

Logical  subscriber  name  of 
artillery  unit  being  rein- 
(oroed  if  own  artillery 
battalion  is  in  reinforcing 
mission  (or  your  backup 
unit) 

— —  Section  number 
—  Platoon  number 
— >  Battery 


Battalion  or  division 


F 


Regiment,  brigade  or 
division 


VREINF - ; 


•  '  »'*  .  •'*  «"•  s*' 


ESTABLISH  A  FIRE  UNIT  IN  THE  AFU  FILE 


■ 


<  C  ONT I NU  E  D  > 


AFU ; UPDATE  ;  PLAN: . ; FU. -/-/-/-- / ,  VPN : . - ;  HODEL : - ; MSN :  —  -  ; 

CORO: - / - / - ;GZ  SPHERE  :-;APPl  --/--;  ST  -  .TONE: - ; 

VST*  AZ  - ;  OF  : - ;  TIMES':  --  - ;  UREINF ;  FSP:  -  /  —  /-  /  —  / - ; 

MAIRNC:  -/ - .-/ - .-/ - ,-/ - , -/ - ; NINRNG - ; TRAVLR : - / - ; 

MAUL  : - :  HASRTE  :  —  .  -  ;  SUSRTE  :  —  .  -  ;  BPLOC :-/  —  /-/  —  ;  FULAT: - .  - ;  BKUP :  -  ; 

DELETE  :-jRT:-;RS:-  ;  READY  OUTTIL :--/--/--; PTEMP: - ; DTC :--/--/-- J. 


REFERENCE  REFERENCE 

>:EP  FIELD  ACTION  STEF  FIELD  ACTION 


FSP 


Enter  logical  subscriber 
name  of  maneuver  force  being 
supported 


Section  number 
Platoon  number 
Company/ troop 
Battalion  or  squadron 
Brigade  or  division 


i -IP:-/-/-/  —  / - 1 


t»  MINRNC 


19  TRAVLR 


10  MAZEL 


Enter  minimum  range  of  tir< 
unit  weapons  in  tens  of 
meters  (0  to  999) 

Enter  left  and  right  tra¬ 
verse  limits  (in>mils). 
Default  -  0400/0400  for 
specified  unit  (0  to  6399/ 
to  6399) 


Enter  masimun  elevation  in 
mils  to  which  fire  unit 
weapons  can  be  elevated. 
Default  •  1200  (0  to  1600) 


>7  MAIRNC  Enter  identity  of  aaauni- 

-*  tlon  (1  to  S)  and  its 

maaimum  range  in  tens  of 
meters  <0  to  9999) 


.*» 


v. 


Ammo  type  legal  entries  are: 

1  ■  ME  normal 

3  ■  HE  eatended 

3*  ■  CH  normal 
4*  «CM  eatended 
5  -  NUC 

(•Also  used  for  white  phos¬ 
phorous  and  illuminating) 

Maaimum  range  in  tens  of 
motors  (0  to  999) 


’1AIRMC : -/ - 1 


21 


22 
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MAIRTE 


SUSRTE 


Enter  maaimum  rate  of  fire 
in  rounds/minute  for 
3-minute  period  for  speci¬ 
fied  fire  unit  (0  to  99.9) 

Enter  maaimum  rate  of  fire 
in  rounds /minut e  that  can 
be  sustained  over  period 
greater  than  3  minutes  tor 
specified  fire  unit. 
Default  -  00.0  (0  to  99.9) 


ESTABLISH  A  FIRE  UNIT  IN  THE  AFU 

<  C  ONT I  NU  ED  > 


AFU ; UPDATE  ;  PLAN: - ; FU: -/-/-/--/ ,  VPN : - ; MODEL  : . -  ; MSN : - ; 

CORD: - / - / . ;  GZ  SPHERE  APPl ST:  -  ;  ZONE: - ; 

VSTR:  —  ;  AZ  : - ;  DF  : - ;T  INERT: - ;UREINF :-/-/-/--/ - ;  FSP:  —  /  —  /  —  /  —  / - ; 

NAXRNC  :-/ - ,  -  / - .  -  / - ,  -  / - ,  -  / - ;  MINRNC : - ;  TRAVLR  : - / - ; 

HAXEL  : - ;MAXRTE  SUSRTE  BPLOC FULAT BKUP  :- ; 

DELETE :  - ;  RT :  - ;  RS :  -  j  READY :  -  ;  OUTTIL PTENP : - ;  DTC —  i 


REFERENCE 
it  FIELD 


ACTION 


REFERENCE 
STEP  FIELD 


ACTION 


BPLOC  Enttr  location  and  distinct 

(in  attars)  of  bast  pitct 
relative  to  battory  cantor 

Dtfanlt  ■  bl ank / 00  0 /b I  ink/ 
000.  If  bast  pitct  is 
over  battory  cantor,  nakt 
no  antry 

—  F  if  bast  pitct  is  forward 
of  battory  cantor:  B  if 
bast  pitct  is  bthind 
battory  cantor 

Dl stanct  forward  of  or 
bthind  battory  cantor 
(0  to  Mt  attars) 


24  Stioct  ont  of  the  two  following  fields 


READY 


OUTTIL 


Enttr  X  it  firt  unit  is 
ready  or  available.  Do  not 
ust  wi th  OUTTIL . 

*  • 

Tint  firt  unit  will  return 
to  action.  Do  not  ust  with 
READY 

—  Day  <0  to  31) 


Hour  (0  to  23) 


Minote(0  to  59) 


OUTTIL:--/  —  /■ 


R  if  bast  pitct  is  right 
of  battory  center;  l  if 
bast  pitot  is  left  of 
battery  cantor 

Distanca  loft  or  right  of 
battery  canter  (0  to  999 

attars) 


27  PTEMP 


21  DTC 


Enttr  powder  teaparatura  to 
be  applied  to  all  anaunitior 
(powar  lots)  for  single  fit' 
unit.  Default  »  +70  < +0 

to  130) 

Enttr  day,  hour  and  ainuta 
of  atssagt 


Enttr  rotation  tint  of  firt 
nnt  t .  Default  ■  2  <0  to  9 
at  not  to) 

Enttr  unit's  radiation 
status.  Default  ■  blank, 
unit's  RS  unknown  (0  to  3). 


DTC ;--/--/  — J; 


Day  (0  to  31) 


Hour  (0  to  23) 


Minute  (0  to  99) 


